Так, вот вам свежее ночное прозрение, пока я пялился в браузер с ИИшкой:

А что если мы не будем просить ИИ написать программу, а попросим его самого стать программой и делать то что нам нужно? Чтобы было понятнее: допустим, вам нужен сервис продажи билетов. Вместо месяцев разработки вы просто говорите ИИ: «Вот схема зала, вот цены, вот эквайринг. Делай красиво, мути бабосики»
И он:
✅ Отдает фронт (и даже адаптивный),
✅ Коннектит базу (и не теряет данные),
✅ Подключает оплату (и не отправляет деньги на свой личный счёт).

Без единой строчки кода, просто добавив ввод-вывод, а ИИ работает как бекенд. Чистая магия: «хочу → получи».

Проблемы, которые пока не позволяют провернуть такой трюк
- Скорость (пока нейросеть думает, мероприятие уже отгремело),
- Надёжность (мы не понимаем что происходит внутри),
- Безопасность (а вдруг скайнет, ну вы поняли),
И наверное множество других, но быть может со временем они решатся.

Eсли подумать, то раньше все эти задачи выполнялись органическими нейросетями, то есть нами. А сложные способы выражения инструкций — это костыль, чтобы обойти ограничения физического мира и объяснить что нам требуется, ибо по-человечески он не понимал. А теперь понимает и возникает вопрос — а нужны ли вообще посредники?

Что думаете, бред или будущее?

P.S.: уже сейчас можно попросить прикинуться линуксом и чятгпт исполнит линуксячьи команды. Попробуйте

Сережа клавиатуры уже паяет, я в автоэлектрики пойду. Попробуйте попросить ИИ найти почему двиган троит, кек

Наконец-то стоящее обновление Intelij Idea в первые за много лет.

JetBrains, проснувшись в холодном поту от кошмаров про VSCode, наконец-то выкатил AI-агента в Idea 2025.1. Да-да, спустя тысячу лет после того, как VSCode уже съел, переварил и забыл об этой фиче.

Раньше их «AI» был обычным чатом-попрошайкой. Как будто вы сами не можете открыть ChatGPT в браузере и спросить, почему ваш код такой позорный. Агент в Idea до недавнего времени был просто декоративным собеседником — бесполезный, как лайк от бота в LinkedIn.

Теперь же у нас, внимание, настоящий AI-агент. Ну наконец-то.
— Осведомлен о проекте. Он теперь реально шарит, что у вас в проекте. Можно спросить: «Где тут все контроллеры с POST?» — и он не начнёт молчать, как вы в неловком разговоре.
— Он умеет редактировать код сам. Представьте, не нужно копировать с StackOverflow сообщение из 2012 года и вставлять его в слезах.
— Он работает с несколькими ИИ-моделями: chat-gpt, claude, gemini. То есть, когда одна начнёт нести чушь, можно переключиться на другую, чтобы она несла другую чушь.

Но — держитесь за стул — плагин платный. 10–20 баксов в месяц, чтобы не страдать в одиночку, а страдать вместе с роботом. Правда, продуктивность от этого растёт. Ну или вы просто быстрее закончите работу и раньше начнёте страдать по другим поводам. Win-win.

Опрос
Вы вообще пользуетесь этим вашим AI, или ещё живёте в 2019?
• ❤️ Я раб ИИ: агенты, чаты, письма, тесты, код — всё на боте.
• 🙊Только чаты, но и на работе, и дома — GPT знает, когда я плачу.
• 😐 Иногда зову чат, когда всё совсем плохо.
• 😢 Никогда. ИИ — это какая-то секта.

Вернемся с ИИ на землю

Как вы наверное знаете, мы с Сережей не очень жалуем библиотеки для мокирования, типа Mockito или mockk и предпочитаем использовать самопальные моки или фейки в качестве зависимостей. Почему так получилось? Есть несколько причин:

1. Не ломается компиляция. В стародавние времена была проблема с библиотечным API — при изменении сигнатуры ломается тест с сообщением вида «ну ваще-т хотели вернуть экземлпяр вот этого типа, но оказывается не подходит», а не компиляция. Сложнее отловить и поправить
2. Каша вместо теста. Из-за того же API тест становится замусоренным, тяжело уловить суть среди нагромождения doReturn-when-блаблабла. Особенно непонятно становится, если нужно эмулировать сложное поведение.
3. Баги в библиотеках. Натыкались неоднократно. Совсем недавно мы обнаружили что mockk не очень умеет в многопоточное окружение. При попытке использовать экземпляр мока по интерфейсу в разных тестах, запускающихся в разных потоках мы вдруг получили что-то вроде No answer found, хотя тесты не используют общее состояние и моки создаются отдельно для каждой функции тестов. В доке особо на этот счет ничего нет, а то что есть — не работает (если кто-то налетал на такое и победил — напишите в комментах)

Самопальные же моки дают бОльшую гибкость, переиспользуемость и читабельность тестов. Хотя они тоже не всегда применимы (например, если нужно замокать конкретную реализацию), да и с компиляцией у библиотек стало заметно лучше и местами мы таки их используем.

И еще одно интересное свойство самодельных заглушек — они позволяют нащупать косяки в дизайне. Если у вас не получается сделать мок, он какой-то кривой, косой и неуклюжий, возможно что-то не так в дизайне или где-то сломался SOLID. Библиотеками же можно закостылять все что угодно, например сделать реализацию только одного метода из 100 в итерфейсы или даже сделать мок для статического метода.

Ни к чему не призываем, это как всего лишь наш опыт и мнение, но если есть возможность — попробуйте

В публичный доступ выложили видосы с конференции за прошлый год. Как всегда много интересных докладов. Для тех, кто хочет стать архитектором, обрести свободу и наконец-то сделать все правильно, рекомендую посмотреть доклад Жизнь архитектора: мечта и реальность (спойлер: вам не позволят) или как спроектантить поиск. Приятного просмотра!

Тут еще мякотки подвезли. Ни для кого не секрет, что электронный мозг умеет галлюцинировать. В коде он делает это с особым изяществом — иногда выдумывает зависимости, которых в природе не существует. На первый взгляд — пустяк. Ну, подумаешь, ваш код дружит с воображаемыми друзьями. Но эти глюки бывают стабильными, то есть повторяются из раза в раз.

Что это значит? А то, что теперь можно весело и задорно проводить атаки на цепочку поставок: находим стабильный баг в бестолковом ИИ, регистрируем репозиторий с нужным названием, начиняем его зловредным кодом — и выкатываем в какой-нибудь npm. Остается только дождаться, пока вайбкодеры втащат зависимость себе.

Похоже рано мы собрались в автоэлектрики. Вангую, что через несколько лет придется разгребать конюшни за ИИ-мастерами.

Источник

Небольшое пояснение

Вообще, мок — это общее название для тестового двойника, но не совсем точное. Потому что помимо моков (mock) существуют:
• Пустышки (dummy) — используются для заполнения параметров, которые обязательны, но не влияют на сам тест. По сути, это просто заглушки, чтобы код не жаловался, что ему чего-то не хватает. Типа как “пригласить на тусу бывшую, но игнорировать ее всё время”. Если ее дернуть, то получишь по-морде исключение, так как взаимодействие не предусматривалось.
• Заглушки (stub) — возвращают заранее заданные значения, которые нужны тесту. Они не записывают, что с ними происходило, а просто делают вид, что они настоящие.
• Шпионы (spy) — записывают, как с ними взаимодействовали: какие методы вызывались, с какими аргументами. Очень полезны, если ты параноик и хочешь знать, кто сколько раз что вызвал.
• Фальшивки (fake) — это полноценные рабочие реализации, но упрощённые. Например, база данных в памяти вместо реальной (H2 или вообще HashMap).

Настоящие моки пошли из этой статьи. Если коротко, то мок — это такой класс, который знает что он будет протестирован, а также содержит методы для верификации. Его можно получить из spy, прикрутив метод проверки чего было вызвано/сколько раз/с какими аргументами/etc. Примеры можете найти в нашем референсе в классах Mock<Something>

Определений можно услышать тысячи, главное понимать суть.

Прежде чем выкатывать в прод новую фичу или целый продукт, имеет смысл устроить так называемые «учения». Суть этих забав — проверить, насколько быстро и точно команда сможет понять, что система уже в агонии.

На первый взгляд напоминает хаос-тестирование, но под другим углом страдания. Если в хаосе мы проверяем, выдержит ли система вцелом, то тут — насколько весело и с каким количеством паники можно будет выяснить, что конкретно пошло по известному маршруту.

Как это работает?
Очень просто: устраиваем контролируемые отказы. К примеру:
⁃ Перестаём слать данные в один из каналов телеметрии
⁃ Забиваем все соединения к БД, как будто пятница и все пошли строить отчёты
⁃ Замедляем или полностью отключаем внешний сервис через какую-нибудь тулзу
⁃ Оставляем один экземпляр бэкенда из десяти
⁃ Ну и другие радости, всё зависит от специфики проекта и ваших SLA

Что происходит дальше? Поначалу, очень часто — ничего. Точнее, внешне ничего. Метрики такие: «всё норм, шеф», алерты мирно спят, в логах тишина. И только редкий вялый WARNING в логах вида «unknown error - operation failed», скромно обозначает, что половина системы уже лежит, а вторая пишет себе завещание. И цель здесь — дотянуть observability до нужного уровня, чтобы алерты орали во всю глотку. Полученные результаты могут быть использованы при организации процесса поддержки и написании соответствующей документации для дежурных админов/разрабов.

Такие учения — это не только способ проверить готовность команды, но и шанс обнаружить серьезные баги (хотя по-хорошему надо бы провести полноценное хаос-тестирование, но и это лучше чем ничего). Потому что если не вы устроите системе праздник жизни — она устроит его сама. В пятницу, в 18:03.

И небольшой лайфхак из нашей практики. Если хотите, чтобы боль преследовала вас на этапе разработки, а не при эксплуатации, то возьмите под один из стендов (для хардкорщиков под препрод) самый дешевый, самый стрёмный хостинг, который только сможете найти. Он постоянно будет сбоить и глючить, зато вы отработаете кучу интересных сценариев, что называется органично. У нас к примеру «отгрызалась» память, терялось сетевое соединение между хостами, отлетали диски и много чего еще интересного. В итоге мы научились реплицировать данные, придумали тулзы для проверки и восстановления консистентности после падений и научились нормально мониторить состояние системы. А самый кек был в том, что машины для прода оказались не сильно надежнее.

Кажется, вы уже заметили, найм в айтишечке — это не просто сломанная система, это кома. ИТ-рекрутинг сегодня — это олимпиада по унижению кандидата, причем очень часто оторванная от жизни. На собеседовании ты вертишь деревья, пишешь алгоритмы, а потом выходишь на работу… и месишь ЖСОНы.

Секция системного дизайна поближе к реальности, хотя давайте добавим еще немного реализма. Для этого нужно всего лишь взять простой советский добавить парочку условий, например:

• В команде — джуны-аутстафферы, проданные по прайсу помидоров. Их погоняют два уставших старшака, один из которых ушёл в отпуск и, возможно, уже не вернётся.
• Верховный архитектор в перманентной войне с вашим менеджером. Каждый созвон заканчивается словами «мне не нравится, переделывайте» без каких либо аргументов.
• Критичные зависимости и сервисы? Их нет, есть только клятвенные уверения, что они появятся к вашему релизу (нет).
• Бюджета на информационную безопасность нет. Можно повесить амулет на сервер.
• Девопс — это человек-загадка, которого выделили вам на 0,2 ставки и он их тратит на дейлик.

Вот теперь это похоже на нормальный проект, а не на глянцевый бред с хабра. И теперь, внимание, вопрос в студию: как будет выглядеть архитектура в таких условиях? Где ваши микросервисы теперь? Лихо всё порежете на деплоймент-юниты или, может, лучше собрать монолит и молиться, чтобы никто ничего не разломал?

ИМХО вот об этом неплохо бы спросить на уровне хотя бы сеньора. А не “сколько времени займет разворот бэ-дерева, если вы к нему привязаны”.

Относительно недавно Сережа писал пост про то, как проходило собеседование в ThoughtWorks , где он в итоге проработал 5 лет (мы его вроде выкладывали тут уже, но может не все видели). Что называется, почувствуйте разницу. Спойлер: спрашивают то, что действительно пригодилось на работе.

Этим летом я завершаю работу в команде разработки электромобиля Атом, где последние 1,5 года руководил группой разработки. Посему, открыт к интересным предложениям.
Что умею и люблю:
🔹 Собирать и растить команды
🔹 Выстраивать процессы разработки — от требований до вывода в продакшен и из него
🔹 Внедрять DDD и чистую архитектуру на практике
🔹 И ещё много всего, о чём можно поговорить лично
Если знаете крутые проекты или ищете человека с моим опытом — пишите в ЛС @elukianov. Отправлю резюме, расскажу подробности.
Спасибо, что читаете! ❤️

Недавно в моей жизни случилось второе великое открытие. Первое было чуть раньше, но давайте по порядку.

Итак, второе открытие: «Похоже, вся индустрия живёт неправильно».
Открытие случилось на курсе по Large-Scale Scrum (он же LeSS) — где рассказывают, как десятки команд в большой организации должны не сожрать друг друга, а как-то взаимодействовать. Вроде бы пошёл узнать про масштабируемый agile, а в итоге залип на самом обычном скраме. Потому что когда тренер начал рассказывать, как на самом деле должен быть устроен нормальный скрам, зал начал слегка дымиться.

Люди вскакивали с мест, ударяли кулаками по столу и кричали:
— Нет, ну оно так не работает!
А тренер невозмутимо, с лицом дзен-мастера, объяснял:
— А вот так оно имеено и работает. Потому что так и задумывалось.

И ты сидишь такой, и в голове проносится:
«Ага, значит не у нас одного daily превращается в ежевечерний дайджест событий за неделю».

- Оказывается, команда вообще-то должна вместе и сообща работать над одной проблемой, а не просто набирать в спринт разрозненные тикеты, как в супермаркете на кассе самообслуживания.
И тогда daily standup перестаёт быть этим унылым «Вера делала таск 123, сегодня делает его же, и завтра, вероятно, будет продолжать с тем же успехом»,
а становится местом, где люди обсуждают, что на самом деле важно — делятся инсайтами, блокерами, помогают друг другу. Живут, в конце концов.

- Или вот ещё: разработчики, оказывается, сами должны разговаривать с кастомерами. Да-да, голосом. С ртом.
А не строить форт из бизнес-аналитиков, чтобы не дай бог не услышать, как реальный пользователь говорит:
«Вот здесь у вас неудобно».

Но вернёмся к первому открытию. Оно произошло после прочтения книги по DDD.
Я вдруг понял: бизнес и код — это не противоборствующие силы. Это не Джедаи и Ситхи.
Это бизнес говорит, каким должен быть код. И ты такой:
«Подождите… что, мы не просто адаптируем бизнес под архитектуру, а наоборот?!»
И вот тут голова сделала пум.

И самое важное — DDD это не про “жутко тормозные проекты с миллионом слоёв и папкой shared/legacy/backup/do_not_touch_final_FINAL”.
DDD — это на каждый день. Это когда у тебя в голове наконец-то появляется язык, чтобы обсуждать с бизнесом суть, а не прокладку между слоями.

И вот что забавно. Обучение по LeSS напомнило мне наши занятия на курсе по кровавому энтерпрайзу, который без слез и сожалений.
Каждую неделю кто-нибудь из студентов обязательно хочет перевернуть стол и крикнуть:
— Нет! Оно так не работает!
А мы с Женей спокойно, как тренер, объясняем:
— А вот так и работает. Просто вы ещё не пробовали.

И вот от чего вам тоже, скорее всего, захочется перевернуть стол:
– Почему code review только ухудшает качество проекта. Да-да, мы вслух это говорим. И даже объясняем.
– DDD в highload-проекте? Почему бы и нет. Особенно если вы хотите не просто выжить, а понять, что происходит.
– CI/CD — это не сервер, а процесс разработки. А сервера может вообще не быть. Он вам не нужен, если вы не знаете, зачем он.

Мы не просто набрасываем, а разбираем почему так. И объясняем, почему за каждой провокацией стоит здравый смысл.
Иногда даже чересчур здравый.

Так что, если вам тоже хочется попереворачивать пару столов — остаётся одно место. Стартуем 31 мая.
Берите каски!

Нам пишут читатели. Живое доказательство что "скрам" -- слово не ругательное. Мы просто его не умеем готовить!

К скраму, как у многих, было скептическое отношение, пока в одно команде сами своими силами не выстроили ровно так, как это в гайдах и описано, не слушая всяких новоиспеченных "скрам-мастеров".
В итоге, команда сама формирует спринт бэклог, цель спринта, работа стала прозрачной, все понимают кто чем занимается. Потому что задачи стали общими, а не у каждого своя. Разработчики вместе с фронтом и дизайнером (разными составами) ходят к бизнесу, вместе рисуют, думают что как.
Оунер занимался только приоритезацией бэклога и приносил в команду проблемы бизнеса исключительно с бизнес формулировкой. А уж как эту проблему решать технически и визуально - задача команды в рамках спринта! Не до спринта, не на груминге/планировании, а именно в спринте.
Как итог, всем понятные оценки (в майках), четкие цели, быстрое и четкое планирование, отсутствие переносов на следующий спринт и даже в рамках эксперимента стабильная работа команды без оунера на протяжении 4 спринтов.

Рубрика: Вредные советы. Антипаттерн: Class Explosion

Описание:
Когда последователи ООП и фан-клуб Мартина Фаулера добираются до кода без присмотра, в проекте возникает эффект ядерного деления: один доменный класс — и понеслась цепная реакция. Через пару спринтов система состоит из 400 классов, каждый из которых делает одну вещь, один раз, в одном месте, и больше никогда.

Симптомы:
• Кодовая база напоминает кладбище интерфейсов.
• Каждый класс делает одну вещь прикрываясь single responsibility principle.
• На прочтение логики одного HTTP эндпоинта уходит столько времени, сколько обычно требуется, чтобы сварить борщ.
• Открываешь PR — там 27 новых файлов. Один валидирует email, другой проверяет, что имя пользователя начинается с заглавной буквы и не содержит проклятий.
• Папки model, core, domain, shared, abstractions, foundation, fundamentals, common, super_common и legacy_common лежат рядом, как косточки динозавра.


Проблемы:
1. Файловая система в панике. Количество дескрипторов растёт, как зарплаты у синьоров на LinkedIn.
2. Компиляция идёт вечность. Зато можно успеть сварить второй борщ.
3. Дебаг превращается в квест. Уже нельзя просто так открыть контроллер, промотать сотни строк кода и найти таки баг в SQL запросе. приходится просматривать множесто файлов.

Лечение:
Мы нашли способ сдерживать бесконтрольное размножение классов. Всё просто: берём ArchUnit или любой другой архитектурный электрошокер и пишем жёсткое правило:

@Test
void `prevent class explosion`() {
    JavaClasses importedClasses = new ClassFileImporter().importPackages("com.yourcompany.yourapp");

    ArchRule rule = classes()
        .should()
        .haveSimpleNameEndingWith("Controller")
        .orShould()
        .haveSimpleNameEndingWith("Service")
        .orShould()
        .haveSimpleNameEndingWith("Entity")
        .orShould()
        .haveSimpleNameEndingWith("Dto");

    rule.check(importedClasses);
}

Теперь всякий, кто вздумает создать Money, UserId или ещё хуже — AggregateRoot, получит предупреждение уже на стадии сборки. А если повезёт — то и выговор.

Вывод:
Классы должны нести гордое знамя своей функции в суффиксе. Всё остальное — ересь. Пусть живут MyAwesomeController, MyAwesomeService, MyAwesomeDto, и никакой самодеятельности.

Сережа забыл добавить, что ни в коем случае незльзя доверять управление транзакциями приложению, всё только в хранимках!

Недавно принесли проект на аудит, насколько он готов для запуска в прод. Вроде бы ничего сложного: бекенд, фронт, мобилка и немного вспомогательных штук. Но оказалось, что весь этот функционал размазан по 50+ репозиториям.

• Половина репозиториев заброшена или содержит только заготовки.
• В некоторых лежат скрипты для ручного вытягивания и сборки соседних реп – это же явный признак, что что-то пошло не так.

Мы не раз говорили: если нет веских причин дробить код – начинайте с монорепозитория. Так проще контролировать зависимости, синхронизировать изменения и поддерживать проект (закон Конвея все еще работает). А когда действительно понадобится — тогда уже можно будет выдернуть кусок в отдельный репозиторий.

Я и сам когда-то плодил репы, зачем-то даже вытаскивал внутренние части приложения наружу, но даже не смог себе честно ответить зачем я так сделал. Поэтому если хотите сэкономить время разработки — не дробите заранее.

Внимание, годнота! Слушатель наших обучалок Артем протащил таки то, о чем мы говорим и теперь ищет себе коллегу.

Наша команда ищет Backend Java разработчика!

Мы работаем над современными проектами, применяя лучшие практики разработки и архитектуры.

В нашей работе мы используем:
- EventStorming — для глубокой проработки бизнес-процессов
- Clean Architecture — для построения масштабируемых и поддерживаемых приложений
- Domain Driven Design — для создания моделей, максимально соответствующих бизнесу
- Trunk-based development — для эффективной и безопасной работы с кодовой базой
- Парное программирование — для повышения качества кода, улучшения понимание кода командой

Были бы рад видеть в команде единомышленника, которому интересно работать без боли и сожалений.
Если заинтересованы пишите @artem_poskrebyshev

В личной беседе Артем сказал, что вообще топчик получился, пожалуй пригласим его на стрим, пусть все сам расскажет.

Особенно приятно когда ребята после курсв могут внедрить эти практики! Отличная работа, Артем! знаю что было не легко!